Mongos distributes bulk updates based on whether the operation is ordered vs unordered and whether the update includes the shard key, routing to specific shards for targeted operations or broadcasting to all shards for scatter-gather execution
When performing a bulk update on a sharded cluster, the mongos router acts as the traffic director, determining which shards should receive which operations. Its distribution strategy depends critically on two factors: the ordered vs unordered setting of the bulk operation and whether the update filter includes the shard key. For unordered bulk writes, mongos can send operations to multiple shards simultaneously, dramatically improving throughput. For updates that include the shard key, mongos performs targeted operations—routing only to the specific shard(s) containing the relevant data. Without the shard key, mongos must execute broadcast operations, sending the update to all shards in a "scatter-gather" pattern .
mongos instances serve as the query routers for sharded clusters, providing the only interface that applications directly interact with . Each mongos maintains a cache of cluster metadata from the Config Servers, allowing it to know exactly which shard holds which chunks of data based on shard key ranges. For write operations, mongos uses this metadata to route each operation to the appropriate shard(s). After receiving responses, mongos may need to coordinate results, though for bulk writes this primarily involves tracking success/failure status across operations .
The ordered parameter significantly affects how mongos distributes bulk write work. With ordered operations (ordered: true), mongos executes operations serially in the sequence provided. Each operation must complete before the next begins, and if an error occurs, processing stops . This sequential approach is generally slower for sharded clusters because operations cannot be parallelized . With unordered operations (ordered: false), mongos can execute operations in parallel and may even reorder them to maximize performance . The MongoDB documentation specifically notes that unordered operations are typically faster for sharded collections because mongos attempts to send writes to multiple shards simultaneously .
Targeted Operations: When update filters include the shard key (or a prefix of a compound shard key),
mongosperforms targeted routing. It uses the shard key value to locate the specific chunk range and directs the operation only to the shard(s) containing that data . This is the most efficient approach, minimizing cross-shard communication and network overhead.Broadcast Operations: When update filters do not include the shard key,
mongoscannot determine which shards hold relevant data. It must broadcast the operation to all shards, each of which executes the update locally on its own data subset . TheupdateMany()anddeleteMany()methods are always broadcast operations unless the query document specifies the full shard key .Multi-shard Routing: For operations targeting multiple distinct shard key values (as in a bulk update array),
mongosroutes each operation independently. With unordered execution, it can dispatch these operations to their respective shards in parallel, significantly improving throughput .
mongos determines target shards by examining the update filter and comparing it to cached chunk metadata from the Config Servers . For sharded collections, data is divided into chunks, each covering a range of shard key values and assigned to a specific shard. When an update includes a shard key value, mongos performs a binary search through its chunk metadata to identify which shard owns the chunk containing that key range. This process is extremely fast and memory-efficient. For updates without shard keys, mongos must default to broadcasting .
A common misconception is that all operations in a bulk array must go to the same shard. In reality, each operation is evaluated independently. For example, if your bulk update contains 10,000 operations with different shard key values spanning multiple shards, mongos will route each operation to its appropriate shard . With unordered execution, these operations can be dispatched in parallel across shards, utilizing the full write capacity of the cluster. This is why unordered bulk writes are recommended for maximizing throughput in sharded environments .
Include shard key in filters: Always include the shard key or its prefix in update filters to enable targeted routing and avoid broadcast operations .
Use unordered for maximum throughput: Set
ordered: falseto allow parallel execution across shards, which can dramatically improve performance for large bulk updates .Pre-split collections: For new sharded collections, pre-splitting chunks helps distribute data evenly and prevents performance bottlenecks during initial bulk loads .
Avoid monotonic shard keys: If your shard key increases monotonically, all new writes may target a single shard, limiting cluster throughput .
Monitor with explain: Use
explain()on representative operations to verify whether they are targeted or broadcast, and to identify optimization opportunities .